The present invention generally relates to streaming media content, and particularly relates to reporting the quality of streaming media content.
Streaming media is multimedia content that is continuously received by, and normally displayed to, a client while it is being delivered by a content server. “Streaming” refers to the ability of an application to play synchronized media streams like audio and video streams in a continuous way while the streams are being transmitted to the client over a network. Streaming media is available over fixed IP networks such as the Internet and more recently over radio access networks via 3GPP's Packet-switched Streaming Services (PSS) protocol TS 26.234.
The Internet Engineering Task Force (IETF) maintains the Real-time Streaming Protocol (RTSP) standard RFC 2326, the Real-time Transport Protocol (RTP) standard RFC 1889 and the Real-time Transport Control Protocol (RTCP) standard RFC 4585. These standards enable streaming media services. RTSP allows a client to remotely control a streaming media server, e.g., by issuing VCR-like commands such as “play” and “pause.” A streaming media session is initiated when a client issues an RTSP ‘DESCRIBE’ command including a Uniform Resource Identifier (URI) identifying a streaming media server (rtsp:// . . . ). The DESCRIBE request also identifies the type of reply data that can be handled by the client. The response sent by the streaming media server includes a presentation description, typically in Session Description Protocol (SDP) format.
Presently, SDP information may be obtained via an RTSP DESCRIBE request or by fetching an SDP file via HTTP, e.g. in Wireless Access Protocol (WAP) applications. When obtained via HTTP, the client already starts with a downloaded SDP file. Either way, the SDP presentation description declares the media types to be used in the session using a codec-specific MIME media type for each media component. Each media type is associated with a URI identifying the location of the corresponding media content.
The client sends an RTSP ‘SETUP’ request to the content server in response to the DESCRIBE request. The SETUP request specifies how each media stream is to be transported. The request contains the media stream URIs and a transport specifier. The transport specifier typically includes a local port for receiving RTP data (e.g., audio, video or text), and another for RTCP data (meta information). The server reply confirms the chosen parameters and fills in missing parts, such as the server's chosen ports. Each media stream is configured using an RTSP SETUP message before a play request may be sent from the client to the server.
After each media stream is configured, the client sends a ‘PLAY’ request to the server which causes one or more media streams to be played. The URI specified in the PLAY request may be an aggregate URI (to play all media streams), or a single media stream URI (to play only that stream). One or more of the media streams may be halted by the client issuing a ‘PAUSE’ request. The client sends a ‘TEARDOWN’ request to the client for terminating the streaming media session. The TEARDOWN request stops all media streams and frees all session related data on the server.
Streaming media servers conventionally request clients to send Quality of Service (QoS) or Quality of Experience (QoE) reports, for indicating quality of streaming media content received by the clients. A QoS/QoE quality report indicates the quality of a particular streaming media session and includes data measured by a client at the transport layer, application layer or both for the metric being reported. While the server requests the client to generate the quality reports, it is the client that determines which quality metrics are reported to the server and when. Presently, six QoS/QoE metrics are defined while others are proposed. Two quality metrics may be applied to the session level—the initial buffering duration and re-buffering duration metrics. The successive loss of RTP packets, corruption duration, frame rate deviation, and jitter duration metrics are applied to the media levels, e.g., audio, video, speech or timed text level. A new QoE metric under consideration by the 3GPP TSG-SA Working Group reports the time that elapses between the initiation of a content switch by a user and up to the time of reception of the first media packet from the new content or media stream (3GPP 26.234 Change Request 0112).
The client also specifies one or more reporting parameters for each quality metric supported by the client. Minimally, a reporting rate parameter is agreed to for each supported metric. The reporting rate parameter expresses the maximum time period in seconds between two successive QoS/QoE reports for the corresponding metric. Optionally, a reporting range parameter may also be specified. The reporting range parameter defines the time range in a media stream for which quality metrics are reported, e.g., the first 40 seconds of media play time. A new reporting parameter related to context switching is under consideration by the 3GPP TSG-SA Working Group (3GPP 26.234 Change Request 0112). The new context switch reporting parameter under consideration measures the duration of a content switch. The client and server negotiate the quality metrics and reporting parameters to be reported by the client. For example, the server may propose an initial set of metrics as part of the SDP description provided to the client in response to an RTSP DESCRIBE request. In another example, the server first makes the proposition at a later stage, e.g., as part of the SETUP response.
However, the client ultimately determines which metrics it will report and according to what parameters. The client is free to negotiate the metrics and reporting parameters with the server, e.g., by including metric proposals in an RTSP SETUP or PLAY request or SET_PARAMETER or OPTIONS method. The metric negotiation process continues until the client receives a PLAY response from the content server. Alternatively, negotiation may be restricted to a number of round trips. Either way, the client reports the metrics and parameters accepted by both the client and server after the metric negotiation process ceases. A metric and parameter are considered accepted by both the client and server when acknowledged accepted by the server, i.e., the server echoes the client's proposal, e.g., as part of an RTSP SETUP or PLAY response. Once a metric is acknowledged accepted by the server, the client no longer includes the same metric in subsequent requests to the server. For example, the client may propose a reporting rate of 10 seconds for corruption duration and 20 seconds for frame rate deviation as applied to a video media stream. The server may acknowledge the reporting rate of 10 seconds for corruption duration but may counter-propose a reporting rate of 15 seconds for frame rate deviation. The client does not include the corruption duration metric in subsequent negotiations involving the video media stream since it has been acknowledged accepted by the server. However, the client may propose a different reporting rate for frame rate deviation or accept the rate proposed by the server. Since the frame rate deviation metric is not yet agreed upon, the client sends a new request to the server with the same proposal (e.g. rate=15) or a new proposal (e.g. rate=10) or instead rejects the metric. The server then acknowledges the proposal in the response. The metric and reporting parameter are agreed upon only when acknowledged accepted by the content server.
Client performance decreases as the number of quality metrics negotiated by the client increases. Under a worst-case scenario, a client may attempt to negotiate two different quality metrics for the session level of a streaming media session and four different quality metrics for up to four different media levels of the session. Client performance is further decreased if the client attempts to negotiate a different reporting parameter for each proposed quality metric. Such extensive metric negotiations degrade client performance, which is particularly a concern for resource-constrained devices such as mobile phones. Further, the bandwidth consumed negotiating a large number of quality metrics and different reporting parameter values can be quite high.
Excessive bandwidth consumption is an even bigger concern when the client subsequently reports the agreed upon quality metrics according to the different reporting rates/ranges. For example, approximately 200 bytes are required to generate a QoE/QoS report and another 80 bytes are needed for the corresponding server response message. Excessive bandwidth is consumed if each supported quality metric is reported individually, e.g., because each supported quality metric has a different reporting rate and/or range. Upwards of 5% or more of a 70 kbps link may be consumed reporting individual quality metrics at different reporting intervals. The high bandwidth needed for QoE/QoS reporting reduces the bandwidth available for transmitting actual data, which is a major concern particularly for bandwidth-constrained devices such as mobile phones. Further, the implementation of the reporting phase is more complex when multiple reporting parameter values are selected because quality metrics are reported at disparate reporting rates and ranges.